Support running DWDS without a Chrome Debug Port (web-socket-based) #2639

jyameo · 2025-06-26T18:15:13Z

Implemented a WebSocket-based communication protocol that provides essential developer tooling (hot reload, service extensions) when Chrome debugger access is unavailable. - #2605
Added WebSocket-based hot reload and service extension support via new WebSocketProxyService class that implements VM service protocol over WebSockets.
Created new files: WebSocketProxyService, WebSocketDebugService, WebSocketAppDebugServices, and WebSocketDwdsVmClient to support socket-based DWDS functionality.
Enhanced DevHandler with useWebSocketConnection flag to toggle between Chrome-based and WebSocket-based communication protocols.

Required Flutter Tools changes: flutter/flutter#171648

dwds/CHANGELOG.md

biggs0125 · 2025-07-18T19:27:53Z

dwds/lib/data/service_extension_request.dart

As a follow-up (in a different change) should we update the ChromeProxyService to also use this Built object for service extensions?

The ChromeProxyService leverages the inspector to evaluate JavaScript expressions via invokeExtensionJsExpression (as seen in the _callServiceExtension method). This pattern is consistently used throughout ChromeProxyService for all interactions with the dartDevEmbedder. It evaluates JavaScript expressions directly in the browser context rather than sending structured messages. Since ChromeProxyService operates by executing JavaScript in the browser, using a Built object here wouldn't align with ChromeProxyService's JavaScript evaluation approach. The current pattern maintains consistency with how ChromeProxyService handles all other browser interactions.

biggs0125 · 2025-07-19T06:17:34Z

dwds/lib/src/connections/debug_connection.dart

+        remoteDebugger.onClose.first.then((_) => close());
+      }
+    } catch (_) {
+      // Chrome proxy service not available in WebSocket-only mode - ignore


What exceptions are we now catching and ignoring here?

If we're in "websocket-only mode" (does this mean -d web-server?) then I would expect the debugger to never even be connected. But if we're not in websocket-only mode (-d chrome?) then it seems like it should at least be a warning if we get an exception here.

Can you add more context on what this is doing?

This was because we were throwing an UnsupportedError in the web_socket_app_debug_services when accessing chromeProxyService. I have changed the logic to return null instead, so we can now simply do: _appDebugServices.chromeProxyService?.remoteDebugger.onClose.first.then((_) { close(); });

~~I believe there could be a debugger connected when in "web-server" mode after the application starts if the user manually connects it using the Dart DevTools chrome extension.~~

Actually now I think I agree, what errors are we swallowing here?

biggs0125 · 2025-07-19T06:20:24Z

dwds/lib/src/connections/debug_connection.dart

@@ -22,9 +22,20 @@ class DebugConnection {
  Future<void>? _closed;

  DebugConnection(this._appDebugServices) {
-    _appDebugServices.chromeProxyService.remoteDebugger.onClose.first.then((_) {


Can this all just be:

_appDebugServices.chromeProxyService?.remoteDebugger.onClose.first.then((_) { close(); });

All the new code here looks to be doing all the same checks as close below.

Done! I've simplified the constructor now

biggs0125 · 2025-07-19T06:23:39Z

dwds/lib/src/handlers/dev_handler.dart

      } on StateError catch (e) {
        // The sink has already closed (app is disconnected), or another StateError occurred.
        _logger.warning(
-          'Failed to send request to client, connection likely closed. Error: $e',
+          'Failed to send request to client ${injectedConnection.hashCode}, '


Does the hashCode actually add any information to these messages? I'm assuming the injected clients don't override hashCode so it'll just be a random number every time.

biggs0125 · 2025-07-19T08:37:15Z

dwds/lib/src/services/app_debug_services.dart

-      debugService.chromeProxyService as ChromeProxyService;
+/// Common interface for debug service containers.
+abstract class IAppDebugServices {
+  dynamic get debugService;


Similar to my suggestion with the proxy services, these should all have common interfaces that we can use here rather than dynamic.

I suspect that with those interfaces AppDebugServices doesn't even need to be abstract. We should just be able to keep the concrete one as it was before. I'm imagining the only change is changing ChromeProxyService chromeProxyService to ProxyService proxyService.

biggs0125 · 2025-07-19T08:43:29Z

dwds/lib/src/services/web_socket_debug_service.dart

+typedef SendClientRequest = int Function(Object request);
+
+// Connection control for WebSocket clients
+bool _acceptNewConnections = true;


I think this is always true, I don't see it ever getting updated to false. So I don't think it's doing anything. Can we delete this and the code using it below?

_clientsConnected seems to be in the same boat.

biggs0125 · 2025-07-19T08:47:49Z

dwds/lib/src/services/web_socket_debug_service.dart

+}
+
+// Creates a random auth token for more secure connections.
+String _makeAuthToken() {


Let's moved this to a shared location and use it both here and in debug_service.dart. Maybe we need a new service_utils.dart file here.

biggs0125 · 2025-07-19T08:54:58Z

dwds/lib/src/services/web_socket_proxy_service.dart

+}
+
+/// WebSocket-based VM service proxy for web debugging.
+class WebSocketProxyService implements VmServiceInterface {


All the duplicated code here from ChromeProxyService can go on the abstract ProxyService and then both of these can just inherit those members.

biggs0125 · 2025-07-19T08:58:41Z

dwds/lib/src/web_socket_dwds_vm_client.dart

+    };
+  }
+
+  static Map<String, Object> _extDwdsEmitEventHandler(VmResponse request) {


Move all these to a shared file. Or probably even better just move WebSocketDwdsVmClient into dwds_vm_client.dart. Then it can share those private members.

nshahan · 2025-07-21T17:32:38Z

dwds/lib/src/connections/debug_connection.dart

+            await chromeProxyService.remoteDebugger.close();
+          }
+        } catch (_) {
+          // Chrome proxy service not available in WebSocket-only mode - ignore


Just like in the setup, it feels bad to see errors being swallowed like this. Can we catch the error we know we want to ignore and surface any others?

nshahan · 2025-07-21T17:50:42Z

dwds/web/reloader/manager.dart

+  Future<Map<String, dynamic>?> handleServiceExtension(
+    String method,
+    Map<String, dynamic> args,
+  ) async {


Is there a missing await somewhere in this method?

srujzs · 2025-07-21T19:14:52Z

dwds/lib/src/handlers/dev_handler.dart

+      await webSocketProxyService.isInitialized;
+      _logger.fine('WebSocket proxy service initialized successfully');
+    } else {
+      _logger.warning('WebSocket proxy service is null');


Is there ever an instance where this is okay? Should we throw/assert instead? Similar question below.

srujzs · 2025-07-21T19:40:52Z

dwds/lib/src/services/web_socket_proxy_service.dart

+          appConnection.runMain();
+          _mainHasStarted = true;
+        } catch (e) {
+          if (e.toString().contains('Main has already started')) {


Do we need to catch this? I would assume the check on line 900 prevents this from occurring.

srujzs · 2025-07-21T19:42:41Z

dwds/web/reloader/ddc_library_bundle_restarter.dart

+    Map<String, dynamic> args,
+  ) async {
+    if (method == 'ext.flutter.reassemble') {
+      await _dartDevEmbedder.debugger.maybeInvokeFlutterReassemble();


I believe this is handled by the calling application i.e. Flutter tools and we shouldn't need to call this ourselves in DWDS. This is how the Chrome-based implementation works. Is there a reason to change that?

disassemble via hot restart should be the same but isn't currently so that makes sense to leave alone.

jyameo added 3 commits June 26, 2025 12:00

implemented socket-based dwds

1fe0895

fix issue with run main at start

2707a41

updated changelog

489dbcc

github-actions bot added the package:dwds label Jun 26, 2025

simulate debugExtension in websocket-based execution flow

a4e0dd0

nshahan mentioned this pull request Jun 30, 2025

Hot restart is broken when running DWDS without Chrome Debug Port #2642

Open

jyameo mentioned this pull request Jul 2, 2025

Support running DWDS without a Chrome Debug Port #2605

Open

1 task

jyameo added 10 commits July 11, 2025 14:30

added multiwindow support

412bda3

refactoring and removing unused method

8f7c645

support page refresh from vsCode

91c7b41

refactor createisolate and resume method

871f388

implemented pause/resume logic

d7dad51

improve canReuseConnection logic

6f40567

comments cleanup

b4d5cb1

fixed canReuseConnection logic

0edf3d8

implemented _handleConnectionClosed and fix issue with getVM

340baad

fix issue with handling isolate cleanup

fa5feb0

jyameo requested review from srujzs and nshahan July 18, 2025 19:12

biggs0125 requested changes Jul 20, 2025

View reviewed changes

jyameo added 3 commits July 21, 2025 12:06

6ba7f5b

addressed comments regarding closing remoteDebugger

afe9fc9

code cleanup

18617bd

nshahan reviewed Jul 21, 2025

View reviewed changes

created common interface for debugService and webSocketDebugService

32f165e

srujzs reviewed Jul 21, 2025

View reviewed changes

Support running DWDS without a Chrome Debug Port (web-socket-based) #2639

Are you sure you want to change the base?

Support running DWDS without a Chrome Debug Port (web-socket-based) #2639

Uh oh!

Conversation

jyameo commented Jun 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nshahan Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jyameo commented Jun 26, 2025 •

edited

Loading

nshahan Jul 21, 2025 •

edited

Loading